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ABSTRACT 


In this thesis, we have considered the problem cf updating 
a dat:i base system based on relational model. Data base is im- 
plemented on TDG-316 computer available in the Computer Centre, 
Indian Institute of Technology, Kaqpur. This forms a part of a 
larger project involvirg building, relt^risval . and security of 
data base. 

In updating we have considered the following three opera- 
tions - 

(l ) Insertion 
(2) Modification 
(2) Deletion. 

Each o-P these three operations can be performed on a single 
relation or the whole data base. Algorithms for these operations 
have been designed and implemented in Basic Assembly Larguoge. 
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1. lUTRODUCTION 


Information updating system works on a personnel data base develop- 
ed at Indian Institute of technology, lianpur as an M.techc project on 
TDC-316 computer. A personnel data base is a data-base vtiich. stores 
information of persons and in our case persons are army officers. Yi/hole 
data base consists of 80 fields and 12 relations, each, relation being 
in third normal form. 

T he values of different fields in a personnel data base are sub- 
ject to changes from time to time, Moreover a situation may arise when 
new records are to be added to or records already existing are to be 
deleted from a single relation on the whole data base. These types of 
operations are called updating. Thus updating consists of three opera- 
tions, nmaely - 

(l ) Deletion 

(2) Modification 

(3 ) Insertion 

Deletion 

In this operation, all the informations of user specified army 
officer (s) are deleted from a single relation or from the whole data base. 
Modification 

In this operation, values of sane fields of seme persons, specified 
by user are modified in a single relation or whole data base without 
creating any new records. 

Insertion 

In this operation, informations of sane new per sens, specified by 
user are inserted in a single relation on vfoole data base in the form 
of new records. 


1 



2 


yJhen updating is based on a single relation m call it "single 
relation updating" and when it is based on all the relations present 
in data base we call it "group relation updatiiig." 

To illustrate updating operation let us consider a data base having 
two relations as follov^St 


Relation R1 


Personnel 

Ro. 

Rank 

Qualifi- j 

cation j 

1 IC-00005 

CAPT 

! 

B.Sc. 

1 IC-00006 

i 

FiAJOR 

P • A • 

5 1 

. IC-OOOl 0 

CiPT : 

B.E. 

1 


Relation R2 


! Personnel | 
1 lo. 

languages j 

Known > 

— — j 

Service Experience j 

IC-00005 

... ^ 

; Hindi | 

5 

IC-00005 

1 

Bengali 

5 

I 

IG-00006 

Tamil 

10 

IC-OOOl 0 

Teliigu 

8 

IC-0001 0 

llalayalam 

8 

IC-OOOl 0 

i 

Panj abi 

! 

8 

i 

1 ^ ' 


1 . Delete 

(a ) Group Relation Deletion : Iiet us assume that an army officer 
having personnel ITo. IG-OOOlO resigns from army and all his informations 
therefore, are to be deleted frcm data base^ These relations after dele 
tion will look like as follows: 
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Relation El Relc^-tion R2 


Personnel ‘ 
No. 

Rank 

Qualifi- 

cations 


Personnel 

No. 

Langtiague s 
Known 

Service 

Experience 

IC-00005 

CAPI 

B.Sc. 


IC-00005 

Hindi 

5 

IC-00006 

MJOR 

B.A. 


10-00005 

Bengali 

5 



i 

1 

J 


IC-00006 i 

Tamil | 

10 


(ii) Sint^le ReJntion Deletion : If the informations of personnel 
No. IC-00010 is deleted from only relation 2 dcj.ta base after deletion 
will look like as follows: 


Relation HI 


'Personnel 

Rank 

Qualifi- 

No. 

cations 

1 

, IC-00005 

Ci\PT 

„ r„.„, _ -L . n . 

B.Sc. 

IC-00006 

ivIAJOR 

B • 

IC-00010 

J i 

CAPT 

B.S* 

s 


Relation R2 


Personnel 

No. 

Languages 

ICnown 

Service j 

Experience 

1 IC-00005 

I 

Hindi 

5 

IC-00006 

Bengali ; 

5 

IC-00006 

Tamil 

10 

. 1 


2. Modification 


(i) &roup Relation Modification : If it is observed that rank, 
qualification, service experience of personnel No. IC-00006 needv^ modi- 
fication, the operation involved is group relation modification because 
the fields to be modified exist in more than one relation. If the rank 


becomes captain, qualification becomes M.A., and service experience 


becomes 12 years and the relations will Imok like - 


Relation R1 


U J- v-'J.i. XI 

Personnel 

No. 

L 

Rank ■ 

Qualifica- 1 
tions ! 

IC-00005 

CAPT 

1 

B.Sc. i 

i 

i 

IC-00006 

MART 

i 

M.A. 

IC-0001 0 ; 

CAPT 

B.E. 


Relation R2 


Personnel i 
No. : 

Languages 

Known 

Service 

Experience 

IC-00005 

Hindi 

5 

IC-00005 

Bengali 

5 

IC-00006 

Tamil j 

12 

IC-00010 

TelPigu I 

8 

IG-00010 

Malay <11 am j 

8 

IC-00010 : 

Punjabi 

8 
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(ii) Single Relortiion -Modification ; If the fields to be modified exist 
in a single relation the operation involved is single relation modifica- 
tion. If only rank and qualification of Personnel No. IC-00006 need to 


be modified, relation E2 in the above case will remain unaltered. 
3 . Insertion 


(i) Group Eelation Insertion: If information of a new person having 
Personnel No. IG-OOOI 5 , say, is to be inserted relations get modified to: 


Relation R1 


Personnel 

No. 

Rank 

Qualifi- 
cations 1 

IC -00005 

CAPT 



B-Sc, 

IC-00006 

IMJOR 

B.A. 

IC-00010 

CaPT. 

B.B. 

1 

; IC -00015 

1 

MAJOR : 

M.Sc. 


Relation R2 


'Personnel 

No. 


Service 

Expe rience 

IC -00005 

Hindi j 

5 : 

IC -00005 

Bengali j 

5 i 

IC-00006 

Tamil 

10 

1 IC-00010 I 

Telxigu j 

8 

; IC-00010 

Malayolam 8 1 

1 IG-00010 

Punjabi ; 

8 1 

IC-0001 5 

Kashmirij 

0 1 

1 


i 


This is group relation insertion because records have been inserted 
in more than one relation. 

(ii) Single Relation Insertion : If Personnel No. IC-00006 learns 
one more longujge only Eelation 2 gets modified to - 


Personnel 
No. ' 

languagues 

Known 

Service 

Experience 

IC-00005 

Hindi 

5 ! 

IC-00005 

Bengali 

5 j 

IC-00006 

Tamil 

10 

IC-00006 

lfe.1<:yalam 

10 

IC-0001 0 

Telugu 

8 

IC-0001 0 

Malayalam 

8 

IC-00010 

1 

Punjabi 

8 

1 i 


This is single relation insertion 
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Special Cases - 

(i) If value of a field for any personnel number is to be deleted 
the operation involved is modification. For example, if we want to 
delete value of field "EAIJK" for Personnel IJo. IC-OOOO5 we have to modi- 
fy this record by putting blanks as value of this field. Helation R1 
after this modification tates the form - 


Personnel 

Ko. 

Rank 


cations ! 

IC-OOOO5 

M 

; 

B.Sc. 

IC-00006 

MAJOR 

B.A. 

IC-00010 

capt 

\ 

1 jB *111 • } 


(ii) If a field is such that it can have more than one value for the 
same personnel nimiber (for example, "Languages Known") and if it is to 
be modified the operations involved are deletion and insertion. For 
example, if personnel number IC-OOOO5 knows language URDU instead of 
HIMLI then all the records for that personnel number are to be deleted 
from that relation first and then new records are to be inserted. After 
this operation R2 takes the form - 


1st Stage (affter deletion 2nd Stage (After insertion) 


Bersonnel[ Languages 
Ro. 1 Khovaa 

Service j 

Experience ! 

Personnel 

Ro. 

Language s 
Known 

Service 

Ex® rience 

IC-00005 

M — M 

i 

5 ! 

IG-00005 

Urdu 

5 

IC-00005 

U — M 

5 


IC-00005 

Bengali 

5 

IC-0Cp06 

Tamil 

10 


IC-00006 

Tamil 

10 

lC-0001 0 

Telugu 

8 


IC-00010 

Telugu i 

8 

IC-00010: 

Maloyalam 

8 


IC-0001 0 

Mai ayulam 

8 

IC-0001 0\ 

PunjoA-bi 

- i 

8 


IC-0001 0 1 

Panjabi 

8 


This operation will be called as special-modification operation, 



2. DESCHIPTIOIT OS’ DATA STRUCTUEES 


Data structures for updating operation are built based on the 
following assumptions: 

(i) Out of three operations involved in updating, namely 
insertion, modification and deletion only one can be 
perfoimed at a time except in the case of special- 
modification operation. 

(ii) Ar^ ITo. of fields can be updated at a time depending 
on the size of data structures. Size has been allo- 
tted such that a maximum of 4 O fields can be updated 
at time. 

(iii) Any number of person’s informations can be updated 
at a time depending on the size of a data structure 
USPITB to be explained latter. 

(iv) Updating is performed either on a single relation or a 
group of all the relations having the saiiB primary key. 

Dor example , if relations 3j5 and 9 are having same 
primacy key, updating of relations 3 and 5 but not 9 is 
not possible at a time. Relations 3 and 5 have to be 
updated separately as single relation updating. This 
type of assumption is quite reasonable due to the fact 
that when some field is updated, our aim will be to 
update all those relations in the #iole data base where- 
ever that field occurs. Updating some relations and not 
the rest may create discrepancy in data base. 

(v) If user specifies seme fields for updating all of which 
are not present in a relation, processing will not be 
deleted but all those fields which are present will be 
updated. 

(vi) In case of single relation updating user has to specify 
the relation but not in group relation updating. 

Dor updating opero,tion user has to specify a file called user file. 
A sample user file is given in Digure 1 


Primary Key 


Dields to be updated 


Personnel No, 


Rank 


Salary 


Qualification 


10-00005 

IC -00008 


CAPT. 

* 


1500 

* 


* 

M.Tech. 


Digure 1 


6 
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Each column ■X)f this file represents a field to be updated except the 
primary key. Each rov/ is a record of user file, A special ch .racter as 
a value of c. field against a personnel number indicates that this field 
need not be updated for tlm-t person. 

In s ingle relation updating, all the fields specified in user's file 
will be updcuted only in the specified rel.ition. In group relation updating 
all the fields specified in user's file will be updated in all those rela- 
tions vdiose primary key is the same as the primary key of user's file. 

In case of deletion user's file consists of only primary key. 

All thefields of user's file are specified by user according to the 
following format: 

LEVEL )6 EIELD HAI.IE FIELD CODE EOEMAI. 

LEVEL = 22 for primary key 
= 44 for filler field 
=02 _ for ordinary field 

=0 to indicate end of field specification. 

Field can be specified either through keyboard or card reader. 

Example 


22 PHITil J6 m 
44 ]6 FILLER X*4.- 
02 ^ EAKK F3 ^ X*6. 

44 FILLER ]6 X*4. 

02 ]6 SALARY :^9 ]6 9*6. 
44 ^ FILLER ^ 1*6. 

02 QUAIF ^ F25 ^ X^g. 

00 , 


Figure 2 

Inform itions of above user's file fields are stored in the following 


data structures: 
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Data. Structure PIiD i 

It stores alphabetic part of field code in one byte. Size of the 
array is 4O bytes. 

Data Structure IifFIiCD; 

It stores numeric port of field code in one byte. Size of the 
array is 4O bytes. 

Data Structure IKFDGrl: 

It stores length of field in one byte. Size of the array is 4O 
byfes. 

Data Structure PI SI; 

It stores distance of this field from the beginning cf a user file 
record in one byte. Size of array is 40 bytes. 

Data Structure LDISI: 

It stores distance of a field from the beginning of a user flile 
record after removing fillers in one byte. Size of array is 40 bytes. 
Data Structure gOBMA: 

It stores format code of the fields specified in user’s file in one 
word. Size of array is 40 words. 

Example 

IS 

When fields are specified in Figure 2 consents of different d^ta 
structures will be as follows - 


FDD 

IHFLCD 

IMFIGI 

DIST 

DDIST 

FOEMA 

F 

1 

8. 

0. 

0. 

030010 

F 

3 

6 . 

12 . 

8. 

q 1 >QoO(, 

F 

9 

6. 

22 . 

14. 

000006 

F 

25 

8. 

34. 

20 . 

03001 0 


Figure 3 
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Thes« data structures are printed in keyboard for user verification. 
Data atructure USFLTB (User Pile Table ) : 

This data structure stores values of fields specified in user file 
after removing fillers. Each byte stores one ch--iracter uud size of 
USPITB is octal 4 OOO bytes. If average length of a record in user's file 
is 40 bytes irformations of 5 O persons can be updated at a time. 

Pield values aare specified either through keyboard or card reader 
depending on user's choice. Each record must be embedded with fillers 
as specified in field specification of user's file. These values are 
stored in USPLTB after removing fillers, Necessity of storing v£iues in 
some area in main memory arises due to the fact thu.t more than one rela- 
tion maj?- haveto be updated in case of group relation updating. An exeimple 
of how to specify values of fields corresponding to Pigures 1 and 2 is as 
follows - 
Record Uo. 1 

lC-OOOO3)iy^0QAB']}.^]6)iM *^]6]6]6j6]6)6 

Record Ho. 2 

ic-00008 MM MMM MM MMM MMM M.Tech.;^ 

Vftien these records are specified through keyboard each record must 
be terminated by a carriage return and when these records are specified 
by punched cards each record must start from a fresh card and one record 
may be punched in 5 cards at mozimum, maintaining the correct size of 
fillers. Each record after checking the correct presence of fillers 
and correct record length is stored in USPLTB after removirg fillers. 

An example of how the above two records will be stored in USPLTB is 
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as follows - 

IC-00005GAM 5 OQ-]6)l>*]6]6y>MMlO-OOOQQ ^]6]6]6]6)i^0j6]6)iLl . Te ch .]6 

So far, the data structiu’es necessary for updating operation hare 
been described. !Ehese data structures are built before the actual 
execution of updating operation starts. Uow other data structures 
which are built during the execution phase will be described. 

Data Structure PDJBLaS 

Before execution of updating operation starts, it must-be checked 
vjhether the fields specified in user file are present in a relation. 

In case of single relation updating, it is expected that all the fields 
specified in user's file are present in the specified relation to be 
updated. If it is not, it must be indicated by flags which fields are 
common between user specified file and the specified relation and only 
those fields will be updated. This is viid for group relation updating 
also^ 

In this case, all the fields which are common between user speci- 
fied file and a relation are updated, 'tfhen some field is found to fe 
comnon, corresponding byte in FEPLAG data structure is set to 1 , else 
it is cleared. V/hen there is no field common this relation is skipped. 

To check -vdiich fields are common between user specified file and 
a relation is done with the help of a data structure PDLIST (field list). 
DDLIST is constructed while building the data base. It stores the follow- 


irg informations: 
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(i) Field codes of fields present in a relation 

(ii) Distance of a field from the start of a record in 
a relation. 

(iii) Format code of field. 

Sizu of is 40 bytes. One byte is reserved for one field. 

Data Structure GIvIPLDS (common Field Di stance ) 

This data structure stores distance of a field from the start cf 


a record in a relation, for tiiose fields whose pDFIulG tiyte is set. (idien 
a field is found to be camaon between user specified file and a relation, 
the distance of the field from the start of a record in that relation 
is read from FDIIST and is stored in the corresponding byte cf GilPIDS. 
Size of C14FLDS data structure is 40 bytes. 

Example 


let us assume FDIIST contains the following informations: 


Eel. Ho. 


Field code Distance 


Fermat 


1 1 

1 5 

1 19 


0 030010 

8 020005 

14 01 01 02 


4 

4 

4 


1 

3 

25 


m 

0 030006 

8 O5OOOIS' 

1 4 O3OOI.C 


6 

6 


1 

25 

9 


0 03001 0 

8 030010 

1 6 030006 - 


Assuming the user file as in Figure 1 with specified fields 
as in Figure 2, contents of different data structures will be as 


follows : 
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V/hile Updating Eel. 1 




IHELOD 


PU'IiAU 

Oi®IDS 

1 


1 

0 

5 


0 

- 

9 


0 

- 

25 


0 

— 

vYuile Updating Rel. 4 




Il'C'LGD 


FDiUaG 

GilFLUS 

1 


1 

0 

3 


1 

8 

9 


0 

— 

25 


1 

14 

V/hile Updating Rel. 6 




INH'LCD 


FUFliG 

GUPIDS 

1 


1 

0 

3 


0 

— 

9 


1 

16 

25 


1 

8 

Following data structures, 

constructed by BUILD subroutine j 

while building the relations, are repeatedly used in updating opera- 
tion. Hence a brief description of these data structures are given 

below. 




Relation Directory (erLDIR): 



This data structure 

stores 

various 

informritions about a relation 

and is stored columnwise 

in memory. A 

sample relation directory is 

shown below in a tabular 

form. 

F-th row of this table corresponds 


to Helation No. 1. 
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RjDLMJM 

RSLID 

PLIIEK 

Tiiro"'^ 

TOTRdO 

KEYEP 

PMKRP 

CRCEO 

lEGTRC 

0 

0 

0 

0 

0 

0 

0 

0 

0 

I 

IhlflE 

R1 

27000 

3 

1000 

PI 

3 0006 

0 

I 

26 

QUALP 

R2 

27040 

2 

500 

P1 

3 0006 

0 

12 


V'lrious coliamns of this table he*ve the following' interpretations: 

EELiroiit : It stores schoracter lor^ name j-iven to u relation. 

ESLID : It stores internal identification number given to a relation* 

Bdmx : It stores the starting address of Primiary Index fable stored 

in memory corresponding to a relation. 

MED : It stores number of records in Primary Index ta’oLe of a rel:;.tion. 

fOTESG : It stores total number of records stored in a relation. 

KSYIiP : It stores internal identification number ofpjteimary key of a 

relation. 

PaiKRP : It stores foim.j.t of primary key. 

CRCEO : It stores overflow cylinder number of a relation. This is to 

be constructed only by insertion operation. 

LEGTRC : It stores record-length of a relation. 

Primary Index Table 

Corresponding to each relation one primary index table is maintained. 
This table stores informations of the type, which are the cylinders used 
to store the relation, highest primary key value in each cylinder and 
number of records in Secondary Index Table corresponding to each 
cylinder. This table is stored rovj-vd.se in core memory. A sample 
primary index table is as f allow sJ 
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Highest key in 

the cylinder 

' ' 

Cylinder 

no. 

IJo. of records in | 

Secondary Index Table j 

IC -0001 0 

' 

13 

1 



100 

i 

IC-00300 j 

1 

1 20 

100 

IC-00350 i 

11 i 

1 44 


I 


Second.:jy Indea T^ible 

Por each cylinder, one secondary index table is maintained in its 
0th surface. Ibis table stores inf orm.-.tions of the type, which sec- 
tors in the cylinder are used to store records, highest primary key 
value in a sector and number of records stored in it. This table is 
stored row-wise. A sample secondary index table is as follows: 


(Ho. of records 

Highe St Primary Key i 

Address of ' 

in sectors 

in sectors 1 

sectors 



10 

IC -0001 3 

41 

8 1 

IC-00025 , 

i 

1 

42 j 

0 ! 

! 

43 i 


Qverflovj Area 

Overflow area is a collection of ^ few cylinders m disk. The 
necessity of overflow area arises in insertion operation, \\hile 
inserting a new record, it may happen tint according to primary and 
secondary index tables either no sectors, no cylinder is allotted to 
that record or some sectors, some cylinder is allotted but no space 
is actually available in that sector, when no space xs allotted, 
naturally record has to be stored in the last sectcr or a fresh 
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sector ort even a fresh cylinder, if necessary. But if a sector is 
allotted, it has to be stored only in th t sector to n^^intain the 
chc.ru.cteristics of Bata Base that records are s.orted before being 
stored. If space is available in the allotted sector there is no 
problem but if it is not available there .ire two alternatives - 
Birst alternative is to move a fev; records from this sector to next 
sector and make space available. But this process is very time 
consuming and dL so tedious due t o the fact that the immediate next 
sector may net have space available in it. In 'tiiat case, record 
has to be moved from one sector to the next sector until some sector 
is feund where seme space is available, Corrfesponding secondary index 
table will hive to be changed drastically. Moreover, if it is observed 
that no sp ace is available in the whole cylinder then transfer of 
records fron one cylinder to another will be necessary until a cylin- 
der i ■ found ''liiere space is available. This will cause changes in 
primary index table also. If no such cylinder is found the record is 
to be stored in a fresh cylinder and primary index table v/ill have 
an extra entry corresponding to this cylinder. 

Second alternative is that when it is found for the first time 
that record does not ^t enough space in the ad.lotted sector, an 
empty cylinder is found out and it is allotted to the corresponding 
relation as an overflow area. Thus each relation will have at most 
one cylinder as overflow area and this overflow cylinder will be . 
allotted to the relation only vixen such an overflow situation takes plac 
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As soon ns, an overflovj cylinder is allotted to a relation this cy- 
linder nmber will be stored in correspondirig entry of this relation 
in GRCNO data structure of relation directory. In first two bytes of 
first sector of overflow cylinder highest sector nunber of overflow 
cylinder is stored which stores records. Records are stored in 
overflow cylinder sxarting f ran second sector. \/hen an overflow 
occurs a free sector of overflow cylinder is f oundout nnd its 
surface-sector number is stored in last 2 bsrtes of the original 
sector from which overflow has occurred. Por subsequent overflows 
in this sector, this will act as a pointer to the overflow sector. 

In this scheme, corresponding to each sector in origintlL cylinder 
one sector is allotted as an overflow sector. Thus during insertion 
operation if overflov; occurs frcm more them 99 SciCtors of a relation, 
operation stops and DBA has to re-arrange his DATA BASE before any- 
more records can be inserted. On the other hand, if there is an 
overflow in the overflo-/ asetor itself, next available sector in 
overflow cylinder will be allotted as overflow area to this overflow 
sector .and process becomes recursive. 

An important point to note is that we ore assuming that last 
2 bytes of each sector are free so that a pointer can be stored here. 
This is consistent with BUILD subroutine which builds the whole data 


base. 



3. CONSTEUCTION OP DiiTA STRUCTURES 

Construction of data structures is the initial phase of updating 

operation. In this chapter, its algorithm is given. Various subroutines 

needed for bhis puirpose are briefly described at the end of this chapter. 

Algo rit hm 

Step 1 : Specify operation. 

Step 2: Is it updating? If yes go to Step 6 el^ go to Step 3. 

Step 3 - Is it retrieval? If yes go to Step 4 else go to Step 5* 

Step 4: Stop. 

Step 5 ’ Is it DBA operation? If yes go to Step 4 else go to Step 1. 

Step 6: Give input maximum for the fields of user’s file. 

Step 7: Is input medium card-reader? If yes go to Step 9 else go to 
Step 8. 

Step 8: Is input mediima keyboard? If yes go to Step 9 else go to 
Step 6. 

Step 9: Specify user file fields through specified input medium with 
primary key as first field and scan it. 

Step 10:Is IiEVEL = 0? If yes go to Step 23 el as go to Step 11. 

Step 11 :Is LEVEL = 22? If yes go to Step 12 else go t o Step 14* 

Step 12:Is primary key already specified? If yes go to Step 13 el^ 
go to Step 19. 

Step 13:Uive message ''Primary Key is Specified more than once, field 
ignored". Go to Step 9- 

Step 14 5ls priaarj' key already specified? If yes go to Step 16 else 
go to Step 15. 

Step 15s Give message "Primary key not yet specified". Go to Step 9, 


17 
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Step 16: Is LEVEL = 44? If yes go to Step 22 el as go to Step 17* 

Step 17: Is LEVEL = 2? If yes go to Step 19 elsego to Step 18. 

Step 18: Give message "Illegal level number, field ignored". Go to 
Step 9. 

Step 19: Transfer alphabetic part of field code to ELL, numeric port 
to lilELCD, fomat to EORIA. 

Step 20: Eind out lei'sgth of field and transfer it to IHELGT, Transfer 
actual distance of field to LIST and distance after removing 
fillers to LLIST. 

Step 21 : Update total length uf user-file-record. Go to Step 9. 

Step 22: Eind out length of filler field. Go to Step 21. 

Step 23: Total number of fields specified = 0? If yes go to Step 9 
else go to Step 24- 

Step 24 : Print contents of data struetiires ELD, IllELCD, Ix^LGT, DIST, 
LDIST and E0E1'4A. Check whether there is any field specified 
such that it does not exist in EDLIST cjr any field duplication 
or wrong fozmjt specification. If yes set EREELG. Go to 
Step 25 . 

Step 25 : BKEiELG is set? If yes go to Step 9, else go to Step 26. 

Step 26: Specify input medium for specifying records uf user’s file. 

Step 27: Specify a record uf user'sfile through ^ecified input medium. 

Step 28: Check whether record length of specified record is correct. 

If yes go to Step 30, else go to Step 29. 

Step 29: Give message "Record length incorrect* Specify this record 
again". Go to Step 27. 

Step 30 : Check whether fillers .are properly placed. If yes go to Step 
32 , else go to Step 31. 

Step 31 : Give message "Eillers are not properly placed". Specify this 
record, again. Go to Step 27. 

Step 32 : Store the jrecord in USPLTB after removing fillers. Increment 
total number of records in user’s file by 1 . 
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Step 33: ilnd of user’s file? If yes junp to processing- phase, else 
go to Step 27 . 

Dnd cf Algorithn. 

lo iaplenent the above olgorithn fallowing subroutines have been 
written : 

(l ) Subroutine IiOOIW (decinal conversion) - 

This subroutines transfers contents cf a word to buffer of 
size 6 bytes to print the content in decinal noto.tion. 

Example - 

J1.IS R2, DGOm 
JOHD HU1,I 
TOED B(JP+6 

WK : WORD 50. 

SUE : WORD 6,0,6 

. = .+6 

(2) Subroutine OOOffV (Octal conversion) - 

This sabroutine transfers contents of a word to a buffer of 
size 6 bytes to print the coatont in octal notation. 

Example - 

JI5S R2, OCOIW 
V/OED 

WORD BIIP+6 

MJTi : JOED 50. 

BUP : JORD 6,0,6 

. = .+6 

(3 ) Subroutine ElOHEK (field ctvecfc) 

This subroutine checks validity of field codes specified in user 
file. Eield codes must have E as alphabetic part cuad non-zero positive 
integer not mere than 80 as numeric part. If there is any field code 
duplication their formats must be different te cause some field may 
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occxir in 2 relations in two different formats. If any of the above 
mentioned conditions are violated for any field specified in user’s 
file EEEPIG- flog is set. Calling instruction, JIIS E3, FICHulK. 

( 4 ) Subroutine PMCIIEK (format check) - 

This subroutine checks whether a field specified in user’s file 
is presmt in PDHST with the sjecified format. If not, it sets a 
flag EREPIG. 

Calling instruction, JMS R3, EMCHEK. 

( 5 } Subroutine ElffinG-T (format length) 

This subroutine accepts forEkit code of a field in octal as 
input and outputs its length. 

Example : 

Jl'IS R5, Ei^'ILROT 
WOlffi EOH.IiiT 
WORE EEl'IGTH 
EOEMAT : WOI© O 3 OOIO 
LEUGTH : .=.+2 

( 5 ) Subroutine PRUSEUL (Print user file) 

This subroutine prints the contents of different data structures 
ELD, IMELCD, IHELGT, BIST, LDIST and ¥01MA for manual verification 
calling instruction, MS R3, PRUSEUL. 

( 7 ) Subroutine BLAIQCB (blank buffer) 

This subroutine puts blanks in a buffer - 


Example s 


JMS R2, ELiUHCB 
WORD BUE+6 
WORD SIZE 

BOE : WORD 100., 0, 100. 

. = .+ 100 . 

SIZE : WORD 50. 


Contents of first 50. bytes of BOE starting froa BUE+-6 will be blanks. 



21 


(s) Subroutine CHEKBL (check blank) 

It checks \7hether contents of a certain area are blank or not. 
if not it sets fl^ EEPIGI , 

Example : 


21.13 R2, CHECKEIi 
WORD HJP+6 
WORD SIZE 
SIZE : .TOHD 2 
HJE ; WORD 100,0,100 
. = .+100 

If contents cf BOR+b and j3DE+7 are blanks ERPIGI is reset else 
it is set. 

( 9 ) Subroutine ElLGIiK (filler check) 

Ihis subroutine checks whether fillers are properly placed in 

/ 

a user file record. If not, it sets a flag EKELG-I . Calling instruc- 
tion JMS R6, PIIiCHK. 

( 10 ) Subroutine STOBB 


This subroutine stores user's file record frco a bixffer to 
USEITB after removing fillers - 
Example - 


TSfi ^USEITB, IOC 
JMS R6, STORE 
WORD LOC 
LOC : WORD 0 

( 11 ) Subroutine DATAIN (Data Input) 

Calling instruction, JMS R5, DaTaIR. 

This subroutine accepts user's file redords- It calls following 


two subroutines 
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(l2) Subroutine KBDIiT (input through keyboard) 

It accepts user’s file records through keyboard calling instruc 

tion: 


JI,IS 13, KBDIIT. 

( 13 } Subroutine GJiRIiIH (input through c ard-reader) 

This subroutine acce pts user file records through c oxd-reader. 
Calling instruction JIIS R3, G^iEDIR. 
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Flov^ohart Phase-I 


STABT 


..L 


Specify type of job 

i 

^ 

/■^ Is it 

retrieval or 
operation? 

M Ho 


\ 


Yes 


STOP 


Ho Is i^v 

" ' - \ updating 

\ ? 

\ -- 
' Yes 


Spe cify identif ration code 


V 


, ' Identification ' 
code correct? '■ 


Ho 


— Give Alarm 


Yes 


Specify input nediiAm for user j 
file fields ! 


"F-’ 


Spe cify user file fields throu^ > 
specified input medium with pid- } 
maiy key as first field. I 


f 
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* 


i Print usar file fields in i 
! teletype ! 


f 



■■ Check from PDIIST whether all the specified : 
j fields and thesis formats are correctly spe- j 
I cified. Also check for duplication of fields, j 


I 

i 


No 


\ 


Field specification is a»rrect? 


/ 


I 

i 

f 


Yes 


i 1 

j Sjscify input medium for user file records. ' 


Specify user file records through specified 
i input medium and store them in U SPITE. 



JUMP TO PEOGESSING PHASE j 

5 



4. PR0G3SSIN& EELAS3 


Faen the data structures h-ve been built, processing of ectuaL 

upd"tin/', op T'tion starts. Here user has to speci^'j What tj^e of upfl'-ting 

op'='rctiaa it is, -’hether insertion, deletion or modification, ^ilso he has 

to specify -ther updating is based on a single rel-tion or group of r*la 

tions. I'" it is single relation, it must be checlsd from PIilIST whether 

the primary key and its form t are correctly specified and other fields 

specified in user file do at all exist .In the specified relation. 

and CLIPIiDS data structures are coreepondingly built. Various informations 

regarding the specified relation are reo,d from rel: tion directory. Delete, 

Insert or Modify subroutine is called de pending on whether the updating 

operation is deletion, insertion or modific.ation respecHEvely- 

On the other hand, if updating is based on group of relctions, all the 

relations are found out from relation directory whose primary key is the 

same as piim-^ry key of user file and the ptscess of single relation updating 

is repented for all these rel''tions. 

Algorithm for processing phase is as folios; s - 

Step 1 : C-lcul-te prim-'r 3 '- and secondary indextable record lengths. 

Initialize BSIOCP to the starting address of USPLIB. Specify 
h'^ther up! ating operation is insertion, deletion or modifica- 
tion. 

Step 2: Is updating operation Insertion? If yes go t o Step 5 else go to 
Step 3. 

S 

Step 3 ' Is updating operation deletion? If yes go to Step 5 else go to 
Step 4. 

Step 4: Is updating operation modifcation? If yes go to Step 5 else go 
to Step 1 . 
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Step 

1 5; 

Step 

6: 

Step 

7 ; 

Step 

8: 

Step 

9: 

Step 

10: 

Step 

11 : 

Step 

12; 

Step 

13: 

Step 

14: 

Step 

15: 

Step 

16: 

Step 

1 ■": 

Step 

18: 

Step 

19: 


Step 20: 


Sp-'Clfy whether upd''ting is based on o. single -rel- tion or group 
o^ rel~tions, 

Isdpdating based on a single rel'tion? If yes go to Step 8, 
else go to Step 7, 

Is updating b^eed on group of rel-^ticn ss? If yes go to St»p 35 j 
else go to Step 5. 

Specify r "1 -tion no. r.nd store it in EEICD, 

Is s];eGified relation no. EELGD less than 1 or greater than 39? 

If yes go to Step 10, else go to Step 11. 

Give message "Relation Ro. v/rongly specified, specify it again". 

Go t 0 Ste p 8. 

Check from relation directoiy whether relation EELGD exists in 
Data Base. If yes go to Step 13, el® go to Step 12. 

Give message, "Specified relation does not exist in Hite Btise, 
specify it again.". Go to Step 8. 

Dram relation directory check ahether primary key cf user file 
is aoDrrectly specified. If yes, go to Step 15, else go to Step 14. 

Give message "Primary key cf user file does not matcBc." Go to 
Step 8. 

i'rom relation directory check whether form't of primary key of 
user file is correctly ^ecified. If yes go to step 17, el® 
go to Step 16. 

GiTO HB ssage, "Eorm t of Primary Key does not match". Go to Step 8, 

Check whether relation EELGD exists in EDLIST. If ye-^ go to 
Step 19, else go to Step 18. 

Give message, "Relation des not exist in EDLIST, Relbtion 
dir-‘ctory and EDLIST are inconsistent." Go to Step 5. 

Check from EDLIST whether there is any field common bfe tween user 
file and the g)ecified relation. If yes, goto Step 21, ^se 
go to Step 20, 

Give message, "Ro common field between user file and the specified 
relation. Inconsistency between EDLIST and relation directory," 

Go to Step 5. 
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Step 21 : Cons-^ruct data structures I'DIJjAG- ad ClffiLDS. Is Ho. of common 
field = 1? If yes go to Step 22, else go to Step 24. 

Step 2'^: Is the updating operation deletion? If yes go to Step 27, else 
go to Step 23. 

Step ?3 : G-i”e message, "Only primary key common between user-^ile ond 
specified relation," Go to Step 5. 

Step 2^1 : Is Ho. of conmon field = total Ho. of fields in us'^r file? If 
yes go to Step 27, else goto Step 25. 

Step 25: Give message, "All the fields specif^ in user file arah v\.(S<- 
present in specified relation. Shall I proceed?" 

Step 26: If reply = yes, go to Step 27, else if reply = Ho go to 'Step 5, 
else go to Step 25. 

Step 21: Read various inform t:ions about relation HSICI) fmom relation 

directory and calculate MAXRC, maximum no, of records in a sector. 

Step 28: Is updating operation deletion‘s If yes go to Step 29^1se go to 
Step 50. 

Step 29; Call subroutine DEL]iIEE. Go to Step 33- 

Step 30: Is updating operation insertion? If yes go to Step 31, else ‘ 
go to Step 32. 

Step 31 : Coll subroutine IHSERT. Go to Step 33. 

Step 3?! Call subroutine MODHY. Go to next step. 

Step 3'' Updatirg is based on sin^e relfcion? If- yes goto Step 34, 
else go to Step 36. 

Step 34: Is operation deletion? If yes go to Step 46, elafe stop. 

Stpp "^5: Assume relation Ho. = 0 and store it in REICD. 

Step 36: Incremat RHLCD by 1 . 

Step 37 ; Is REICD 39. If yes, go to Step 34, else go to Step38. 

Step 38: Check from reltion directory whether relation RE'lDD exists 
in D'^ta Base. If yes go to 9-t^P 39, else go to Step ’’6. 

Step 39: Prom relation directory check whether piriiaary key o-^ user file 
matches. If yer^ go to Step 40, else go to Step 36, 
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Step 40 : 

Step 41 ; 
Step 42 : 
Step 43 s 

Step 44 s 
Step 45 s 
Step 46 ; 


Prom relation lirectory check whetherf-f'orm-t of primary 
key of user file matches. If yes, go to Step el^ie 
go to Step 36. 

Check vjhether the relation exists in PDLIST. If yes go to 
Step 43 > else go to Step 42. 

Give message, "Relation diaeectory and PDLIST are inconsistont" 
Go to Step 36. 

Check -^rom PDLIST vhether there is any fieli common bet^reen 
user file and fields present in this relation. If yes go to 
Step 44, else go to Step 42- 

Construct data structures PDPLAGand GlffiLDS. Ij No. of common 
field = 1? If yes, go to Step 45, else go to Step 27* 

relcrtlon ? 

Is updating openation delettion'?^ If yes, go to Step 27, else 
go to Step 36. 

Is operation fecial modification? If yes go to Step 6 of 
Phase I algoritbua^ else Stop. 


Dnd of Algorithm, 

A bri'.f account of different subroutines written to implement this 


algorithm is given below; 

(l ) Subro^ tine GOLIBID (Compare Relation Directory)- 

This subroutine compares primary key of user file and its format 
with corresponding entries in relation directory for a given relation 
No, EEICD. If primary key matches it sets a fl^ PKPLAG and if its 
format also matches it sets a flag K^IPLAG, else both flags are reset. 
Calling instruction is 3 l'I3 E2 , CO 1.IHID. 

(2) Subroutine REAPED (Read Relation Director) 

This subroutine reads various entries in relation directory corres- 
ponding to relation No. BSLCD. Calling instruction is JIILS R2, RRADRD. 
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(3) Subroutine COFyEP (Convert Reply) 

This subroutine converts a number stored in ASCII code in a buffer 
EEPIY of si-^^e 6 bytes to binary code and stores it in a v/ord. 

ExampHe : 

Jl-lS R2, GOBrVRP 
WORD HSLGD 
R3PIY : WORD 6,0,2 
BYTE 61,62 
. = . + 4 
ESICD : . = . + 2 

Content of EEICD will be 12- 

(4) Subroutine OOMIvIPG (Common Field Check) 

This subroutine checks whether a relation number EELCD exists in 
EDLI0T, If it exists, it sets a flag CMPIiPL. Also if RSLCD exists in 
EDLIST, it compares fields of user fine with fields present in relation 
EELCD, and their formats, atid orrespondingly it constructs data struc- 
tures EDELAG and CMEIDS- It also stores total number of common fields 
in ROOMEL, Calling instruction is IMS E7, GOlIMFO. 

In the next few chapters, algorithms for insertion, modificaticn 
and deletion operations have been described. This will complete proces- 
sing phase of updating operation. Symbols used in liiese algorithms have 
the following interpretations : 

ERECP = Serial Ro, of re coxa currently being processed in user fi3e . 
OVEECY = Overflow cylinder number corresponding to relation EEICD, 
currently being updated - 

ASIOCP = Pointer to starting location of primary key value in a record 


in sector 



30 


SLOCR = 
URDATI’ = 

OVEEF = 


MCTRS = 


ACTLRO = 
MTIMED = 
I'IaXEC = 
COUNT 6= 
BSLOCP = 
ACTIEL = 
NIN 

SIBTL = 
PINTL = 


lointer to storting location of a record in sectes- 
A flag which TJhen set indicates that at last one record has 
been updated in the sector currently read. 

A flag which when indicates that currently updating is going 
on in the overflow urea. 

No. of records in sector already tested for primary key value 
matching. 

Total No. of records in user’s file. 

No. of records updated in the sector currently read. 

Maximum possible number of records in a sector. 

A counter which counts number of records in sector currently read. 
A pointer which points at the stfjxting of a record in user file. 
Length of a record in user file . 

No. of records in primary index table. 

Secondary index table record-length. 

Primary index table record-length. 
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Flowchart for Processing-Phase 


/ 

\ Processing Phase starts '' 

\ 

g 

: Calculate primary and secondary index table record ; 
j lengths. Initiolize BSLOCP to starting location of ■' 
j USFIT3. 


I Specify whether updating is insertion, deletion or 


modificati on. 


i B > 

I - / 


.--J 


Specify whether updiiting is on single reh. tion or' 
group of relations. ! 




4 


Is updating based on single rel±ion 


Ho 




Yes 

J 


SjB cify relation code and store [ 
it in EELCD. 1 


Is I^EEICI) / 


Yes 


D 


■Ho“ 


-/ 


Do relation HBIOD exist in relation direct oiy, 
prim ry key of user file and its format mthh with 
corresponding entries? 




\ 

/ 


& 


Yes 
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j 


I Prom PDLIST find out how many fields are ; 
i coiamon b -'tween relation RSLCD and user ‘ 
^ f ile c Also construct data structures j 
i OmmS aA PDIIAG, i 


/ri- 


Is No. of common field = 0? '''' 
\ / 


\ Is No, of common field = 1? 
\ 


Is operation deletion? 


Give message "No field can be updated. ! 




Jill the fields present I'n user file are '' 
\ present in relation BBICD. 


/ Ask whether processing diould continue, 
\ Should it continue? 


-tisp-yg g 


j Read various entries of relation directory j 

i for relation RBLCD. Galcul.ite MXRC. Ini- | 
i tialize BSLOCP to starting location of USPUB. i 


! 
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pi 


C Is opeiation deltion? 


Yes 


/ 


Jimp to delete 

. . 1 ? 


,• subroutine* 


^ ? 
! t 


/ Yes 

V Is operation nodifi cation? 


No 


I Jump to insert subroutine 


Jump to Modify ^ 
subroutine* \ ^ 


No 




: ^ Is operation based on single 

relation? 


Yes 


/• 


\ Is it delete operation? 


Fo 

/• 


Yes 


/ Is it special modify operation? 




Yes 


Jump to Step 6 cf Phase -I 
algoritlm. 


-ISTOP' 


No 
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EEIiCD = 0 


i " 3 - 


' fiELCD = EELGD+1 


/ 

\ 


'' E 


:£ 


- 

£ i Is EELCD 4 39 


■T\ 

, y 

V 


Eo 


Yes 




Do relation EELCD exist in relation 
directory, primary key of user file 
and its form^it match with correspon- 
ding entries? 


Yes 


From FDLIST find out how many fields 
are common between relation HEIGD and 
user fi]e . Also construct data struc- 
tures OilFLDS, EDFIuid. 


Yes 


Eo 




No. of common field = 0? 

i 

No 

'( _ 

No. of common field =1? 

i 

j 

1 

_J 

Yes 

L . 

N 

Is it delete operation? '' 

X 

/ 


}' 

1 

j Yes 

n 

\ 
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5. DELEDIOK 


Deletion is an updating operation Yi/here sam.e records from, a relation 
Or a group of relations ore deleted. V/hen records are deleted from a sin- 
gle relotion, it is called single relation deletion and when they are dele- 
ted from a group of relations it is group relation deletion. Dor perso- 
nnel data base, example of single relation deletion is a situation where 
it is observed that due to seme reasons, inform.abions stored in a redation 
are no longer relevant for a person and example of group relation deletion 
is a situ'ition where a person leaves the organization. 

In deletion operation, user file consists of only one field, the 
primary key of user file. If more than one field is specified all the 
other fields except the first one mil be negdseted. A sample user fide 
is given below - 

Personnel Uo. 

IC-00050 

IG-00060 

IC-00065 

Before giving algorithm for delete operation, a brief descripfcion of 
a few subroutines, written to implement this algcarithm is given sd that 
the algorithm can be presented more easily. 

Subroutine READ (Read a Secctor) 

This subroutine stores the contents of a sector in an assigned 
area in core memory. 


35 




36 


Example - 

MS E4., READ 
WORD CyiKDE 
WORD SURSEC 
WORD AREA 
CYIRDR: WORD 100. 

SURSEC; v/ORD 1 
ARIA : . = .+400 

Contents of Sector No. 1 of cylinder No. 100 will be stored in AREA. 
Subrou tine Y'f RITE (Write on a Sector) 

This subroutine stores the contents of an area of size 256 bytes in 
a sector. 

Example - 

MS R4, WRITE 
WORD OYLNUR 
V/ORD SURSEC 
WORD AREA 
CYINDR: WORD 50. 

SURSEC: WORD 2 
AREA : . = .+400 

Contents of AREA is transferred to second sector of cylinder No. 50. 
Subroutine TRSUSE (Track, Surface, Sector) 

Given a primary key value as input, this subroutine searches primary 
and secondary index tables to find cylinder number and surface-sector 
address in which a record of this primary key value should exist. 

If primary index table search is successful, it sets a flag MTOHPR 
else it is reset. If secondary index table search is successful it sets 
a flag MTCHSR else it is reset. If both searches are successful, it 
stores cylinder number ifl CYDNDE, total n-umber of records in secondary 
index table in NRECSE, surface -sect or address in SURSEC, total n-umber o£ 
records in this sector in NEBCST. Assuming first record of index tables as 
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0"bh.j rscordj tiliis subroutine stores the record number of priDi<nry index 
table Lit which matching took place in COUHTO, record number of first 
secondary index table in GOUMTI and record number of subsequent secondary 
index table in C0UNT3. 

Example - 


TSR/=PKYVA1, SLOOP 
JliS E3, TRSUSE 
WORD SLOOP 

PKYVAL: BYTE 'I, '0, 40,60,60,60,62,60 
SLOOP : . = , + 2 

Subroutine OOMPEQ (Oomp,are fear Equality) 

This subroutine compares contents of two areas for equality. If 
equal, it sets a flag EQELiiG else it is reset. 

Example - 


TSR /AREA1 , L001 
TSRj^AEEA2, LOO 2 
MS R2, OOMPEQ 
WORD LOCI 
WORD L0C2 
WORD SIZE 

AREA1:BYTE 'I, ’0,40,60,60,60,62,60 
AREA2:BYTE 'I, '0,40,60,60,60,62,60 
SIZE : WORD 8.| size to be compared. 

In this case EQELAG is set. 

Subroutine BLAMKA (to Blank Area) 

This subroutine puts blanks in a given area. 

Example ; 

TSR/BUPl, SLOC 
TSR/10., SIZE 
MS R2, BLANKA 

WORD SLOC; starting loation 
WORD SIZE 

BUE1 : . = . + 100 

SIZE : . = . + 2 

Contents of first 10. bytes of BDE1 will be blanks. 
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Subroutii e SUSji! (Surface-Seotor ) 

G-iven a primary key value and cylinder number of a cylinder in which 
a record corresponding to this primary key value exists, this subroutine 
searches secondary index table* If search is successful it sets fiag 
MTCHSR and stores furnace— sector number in SURSEC. This subroutine is 
a part of subroutine TRSUSE. 

Example - 

TSR/ PKTVAL, SIOCP 
JMS R3, SUSE 
WORD SIDCP 

PKIVAI: BYTE 'I, '0,40,60,60,60,62,60 
SIOOP : . = . + 2 

Algorithm for delete operation is as follows - 
Step 1 : Initialization, NEEOP = 0; Rind OVEROY. 

Step 2: Initialize ASLOOP, SIOORj Reset flags UBDATE and OTERP; M0TRS=0; 
MGCP = RREOP+1 . 

Step 3: Is NREOP >■ ACTLRC? If yes go to Step 4; else go to Step 5, 

Step 4 : Return to calling program. 

Step 5* Print record No. NREOP and call subroutine TRSUSE. 

Step 6 : MTCHPR = set? If yes go to Step 9; else go to Step 7. 

Step 7: Give message, ’'Primary Index Table Search fails". 

Step 8: Take next record in user's file. Go to Step 2. 

Step 9 : MTOHSR = set? If yes go to Step 11 | else go to Step 10. 

Step 10: Give message, "Secondary Index Table search fails". Go to Step 8, 
Stop 11 : Is NRECST = 0? If yes go to Step 12| else go to Step 13. 

Step 12: Give message, "Record does not exist in sector". Go to Step 8, 
Step 13 iHTTMED = 0. 

Step 14: Read sector SURSEC of cylinder No. CYINDR. 
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Step 15: 00UNT6 = 0. 

Step 16: COUNTS = C0UHT6+1 . 

Step 17: Is NACTRS <;' NEUCST? If yes go to Step 18| else go to Step 28. 

Step 18: Is COUNTS ^ MAXEC? If yes go to Step 23? else go to Step 19» 

Step 19: Check whether priia.iry key value is blank of c\irrent record in 
sector. If yes go to Step 22; else go to Step 20. 

Step 20: NACTRS = NACTES+1 . Compare primary key values of this record 
and user file record. Are they equal? If yes go to Step 21 ; 
else go to Step 22. 

Step 21 : Delete current record in sector. Set UPDATE flag. NTIIIBD = 

NITEMD + 1. 

Step 22: Consider next record in sector. Go to Step 16. 

Step 23: Is flag UPDATE = set? If yes go to step 24; else go to Step 25. 
Step 24: Write back Sector. 

Step 25! Is OVERCy = 0? If yes go to Step 26; else go to Step 27. 

Step 26: Give message, "Secondary index table inconsistent." Go to Step 28. 

Step 27: Erom last two bytes of current sectors read pointer to overflow 
sector. Set OVERE flag. Initialize ASIOCP, SLOGR. Read over- 
flow sector. Go to Step 15. 

Step 28: Is UPDATE = set? If yes, go to Step 29; else go to Step 12. 

Step 29: Write back sector. Updfxte secondazy index table. 

Step 30 : Comp are primary key value of user file record with highest 

primary key entry in current record of secondary index table. 

Are they equal? If yes go to Step 53; else go to step 31. 

Step 31 ! Write bc^ck secondary index-table. 

Step 52: Give message, "Record Processed". Go to Step 8. 

Step 33: C0UNT3= C0UNT3+1 

Is the current record of secondary index table last record? 

If yes go to Step 38; else go to Step 34* 

Step 34: Is primary key value of record No. 0CUNT3 in secondary index 
table ^ primary key value of user file-record? If yes go to 
Step 35; else go to Step 31* 
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Step 35- Hend SUESEC and NEEOST from current record of secondary index table. 

Step 36: Is IffiEOST = 0? If yes go to Step 30; else go to Step 37. 

Step 37: Initialize ASLOCP, SLOCR; MCTRS = 0, NTD/ED = 0; go to Step 14. 

Step 38: V/rite back secondary index table. COUHTI = OOUlT+1 . Read secondary 
index table from first sector. Is highest primary key entry in 
record Wo. C0UNT1 blank? If yes go to Step 39, else go to Step 40. 

Step 39: Read NRECSE and SUESEC from current record in seoondaiy index 

table- Read secondary index- table from sector SUESEC. COUM'3 = 0. 
Gro to Step 34. 

Step 40: COUNTO = COUETO-f-1 

Is COUWTO = WIN? If yes, go to Step 32; else go to Step 41. 

Step 41 : Is highest primary key values entry in current record of primary 
index table ^ primijry key value of user file record? If yes go 
to Step 42; else go to Step 32. 

Step 42: Read OYIilCDR, NRfiCSE from current record of primary index table. 

_ , . ' I . Call subroutine SUSE to find 

SUESEC. MICHSR = set? If yes, go to Step 36; else ^o to Step 32- 


End of Algorithm. 
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Flowchart for DELETF 


■< Subroutine DEIETE 




HEiECP = 0; Find OVERCY 


Initialize ASIOCP, SIDCR 




I HRECP = URECP+1 ; clear flags 
i UPDATE, OVERPi 1.GTRS = 0 


4a 


BEIDCP = BSIDCP 
+ACTIRI 


r" Is HRECP ACTIRC 


Yes 


EETUEH 


iNo 


, Ho__ X RECORD HO. HRECP. JUMP TO 

l'*'" ' ’X TRSUSEmTCHPR = set? 

fails" 


Ho 


Yes 


MTCHSR = set? ^ 
\ 


Yes 


Record does 

[ Yes 

./ HREGST = 0? 

not exist in 


*V . 


sector j 







Ho 


\ HTIMED=0 ■ 

n^' ’! 


!- i 
' 
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/'is UPDATE = set?"\, 



Wo 
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Wo„ 


( 

"\ 


Write back secondaiy index table; 
C0U1TO1 = COUNTI+li Bead secondary 
index table; check record no, 
COUMPI in secondary index table 
for blank. Is it blank? 


\ 


\ 



Yes 

Calculate MbiOSE, SURSEO. Read 
secondary index table COUIWJ = 0 


H 


/ coumo = COUHTO+I \ 

Is C0UNT0= CT? 


Yes 



No 




6, MODIFICATION 


Modification is an updating operation where values of different 
fields o-P some records are modified, "'^en this operation is perform- 
ed on 0 single relation it is called single relation modification and 
when it is performed on all the relations it is called group relation 
modification. For personnel data base, example of modification opera- 
tion is a situation when some persons get promotion and their ranks 
and salary are to be updated. If all these fields except the primary 
key occur only in one relation it is single relation modification and 
if these fields occur in more than one rel ition or different relations 
it is group relation modification. 

In modification operation user file consists of primary key and 
the fields to be modified. A sample user file is as follows - 


Personnel No, 

Rank 

Salary 

Qualif . 

10-0005 0 

10-00056 

10-001 1 0 

OAPT. 

MJOE 

* 

1600 

1400 

i 

j * i 

¥r 

Mia . A • 

M.Tech. 


Symbol * (stiir) «s value of afield indie xtes that 
value of this field remains unmodified for the corres- 
ponding primary key value. 

Algorithm for modification is similar to algorithm for deletion 
except a minor change that instead of deleting a complete record, 
values o--’ di-^ferent fields are modified. Subroutines used in modi- 
fication operation are already explained in previous chapters ezcept 
the following - 
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(l ) Subroutine IRAl'S (Transfer) 

This subroutine transfers the contents of an area of a specified 

size with specified starting location to another areci who as starting 

location is specified. Example - 

T SR /SOURCE, IOCS 
TSR/RESTF, lOCD 
Jl^S R5, TRJi® 

WORD LOCS 
WORD LOCD 
WORT' SIZE 

SOURCE : BYTE 1,5,9., 10., 12, 4 
DESTIT : . = » + 1 00 
SIZE : WORD 4 

Contents of first 4 bjrtes of DESTU will be 1,5)9*? 10. respectively. 
( 2 ) Subroutine TRATTR (Transfer attributes) 

This subroutine modifies a complete record. Elowchart for this 
subroutine is given below. 


( Subroutine TRATTR 



Calling Instruction of this Subroutine is JMS R2, TRATTR. 
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Algorithm for modification operation is as follows - 

Step 1 : Intialise HDECP = 0, Pind overflow cylinder number corre ponding 
to relation SiilICD and store it in OVERCYo 

Step 2: Initialize ASLOCP, SLOCR. Increment IffiECP by 1 . Reset flags 
UPDATP, 07RRP. Initialize ILiGTRS = 0. 

Step 3: Is irRSCP> ACTIRS? If yes go to Step 4; else go to Step 5. 

Step 4: Return to calling prcgr^. 

Step 5 - Print record nmber IIRECP and call subroutine TE3USE. 

Step 6: MTCHPR = set? If yes go to Step 9| else go to Step 7* 

Step 7 : Give message "Primary index table search fails." 

Step 8: Take next record in user’s file. Go to Step 2. 

Step 9: MIGHSR = set? If yes go to Step 11s else go to Step 10. 

StepiO: Give i]£ ssage "Secondaiy index table search fails". Go to Step 8. 
Step 11 : Is HRJ3CST = 0? If yes go to Step 12 j else go to Step 13. 

Step 12: Give message "Record does not exist in secttor". Go to Step 8. 
Step 13: Read sector SURSaC of cylinder number CYIKDR. 

Step 14: COUHT 6 = 0. 

Step 15: OCOm 6 = OOUHT 6+1. 

Step 16: Is MCTRS < NREGST? If yes go to Step 17; else go to Step 27. 

Step 1 7: Is C0UIW6 KhlXRO? If yes go to Step 22; else go to Step 18. 

Step 18: Gheck whether primary key vrlue is blank in current record of 
sector. If yes go to Step 21; else go to Step 19. 

Step 1 9 : MCTRS = MCTRS + 1 . 

Compare primary key value of this record and that of current 
record in user file, iire they equal? If yes go to Step 20; 
else go to Step 21 . 

Step 20; Gall subroutine TRATTR to modify this record and set fleg 
UPDATR in case there is any modification. 
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Step 21 : Consider next record in ®ctor. Go to Step 15, 

Step 2?J Is fl.og UPDaTF = set? If yes go to Step 23; else go t o Step 24- 
Step 23: Write back sector. 

Step 24: Is OVilEOY =0? If yes go to Step 25; else go to Step 26. 

Step 25: Give messroge "Secondary index table inconsistent". Go to Step 27- 

Step 26; Set flag OVEEI*. Prom 1st two bytes of currant sector read 

pointer to overflow sector. Initialize aSLOGP, SDOCR. Read 
overflow sector. Go to Step 14- 

Step 27: Is UPDATP = set? If yes go to Step 28; else go to Step 12. 

Step 28; Write back ®ctor. 

Step 29: Compare primary key value of current record in user file with 
highest key entry in current record cf secondary index table. 

Are they eq.ual? If yes go to Step 31 1 else go to Step 30. 

Step 30: Give message, "Record processed". Go to Step 8. 

Step 31 : C0URI3 = C0Ul'irT3+1 - 

Is the current record of secondary index table last record? 

If yes go to Step 36; else go to Step 32. 

Step 32; Is primary key of current record in user file highest key 
entry in record ilo. 801115113 of secondary index table? If yes 
go to Step 33; else goto Step 30. 

Step 35; Ee 'd SURSEC, HRfiCST from secondary index table. 

Step 54: Is RRECST = 0? If yes go to Step 29; else go t o Step 35- 

Step 35: Initialize ASIOCP, SIOCR. Initialize, MCTRS = 0. Go to Step 13- 

Step 36: C0UNT1 = C0UIT1+1. 

Read secondary index table frcm first sector of cylinder number 
CYLHDR. Is highest key value entry in record niraber COUIWI blank? 
If yes go to Step 37; else go to Step 38. 

Step 37: Rend RRECSE and SURSEC from ciorrent record in secondriry index 

table. Read secondary index table fraa sector SURSEC. Initialize 
C0UM13 = 0. Go to Step 32. 
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Step 58 : COUIff 0 = G0UM)0+1 . 

Is COUKTO = ETIir? If yes go to Step 30; else go to Step 39- 

Step 39 : Is highest key entry in current record of primary index table 
^primary key value of current record in user file? If yes 
go to Step 40j else go to Step 30- 

Step 40: Read CYLTOE, IIRECSt!) from primary index table. Call subroutine 

SUSfi to find SURSEG. Is flag MTGHSR = set? If yes go to Step 34 
else go to Step 30. 


End of Algorithm. 
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Flowchart for Modification 


Subroutine MDDIFY 


\ 


j IIREOP = O5 Find OVERGY 



1 Return! 
1 t 









! Read sector SDESEC from CXXlffiR < 


COUNTS = 0 : 

i I 

i — 

GOUMTfi = aOIJIW 6 +l I- 


B 


Is HACTRS KRECST?^ 


Yes 



■ Ro 

i 

”"Set 0 VERB 5 Rind SURSEoT 
Initialize ASIDCP» SIDCR* 
Read overflow area. 


I, I. r. 

ISNUt,’ 




KANPUR 

i. ! : 'iRARY 

~ !)W2 
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< Is UPDATE = set? 


Write back sector i 


Is primary key value of current 
record = Highest key entry in 
current record of secondary 
indeed table? 


'Record s 
processed"! 


Yes /’" \ 

Q / Is it last entry cf secondary ^ 

index table? 


1— No 


Call subroutine COMPRI; 
MTCHE = set? 



Read SURSEC, NREGST 



<^HRECST = 0?_p> 



Initialise ASliOCP, SIDOR; 
NAOTRS = 0. 
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Read primary index table and call SUSE 
to find SURSEG 






7. IHSEICDIOIJ 


Insertion is an updating operation where sane new records are 
inserted in data base. Vflien records ore inserted in a single rela- 
tion, it is single relation insertion and when they are inserted in 
more than one reLition, it is group relation insertion. A sa 
user file for insertion operation is as follows - 


Personnel ETo. 

Rank 

_Sal.my... 

Qualif i c at i cn 

IC -00050 

IC -00056 

IC-001 1 0 

CAPI. 

MJOR 

— 

1600 

1400 

* 

M.a# \ 

M.Iech. i 

f 


If all the fields sincified in user file except the primary key 
occur only in one relit ion it is single relation insertion and if they 
occur in different relations or more than one relation it is group rela- 
tion insertion. Symbol * (star) as value of a field indicates that value 
of this field is left blank for the corre^ ending primary key 7/hile 
inserting this record. Different subroutines used in insertion opera- 
tion are expl.ained in previous chapters except the fallowings: 

(l ) Subroutine ALIOGT (Allocate a Cylinder) 

This subroutine finds out cylinder number of the first available 
empty cylinder in disk starting from cylinder number 0 and stores it in 
0V15RCY. This cylinder is used as overflow cylinder. Calling instruction 
is JMS R4, ALIOCT. 
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(2 ) Subroutine lOISEO (Uext Sector) 

This subroutine finds the sector nunber of a sector next to sector 
number SUESEG and stores it in ItelWSS* Calling instruction JTdS R4, MXIPSEC. 

(3 ) Subroutine PUT 

This subroutine va^ites back primary index table on disk. Calling 

instruction is JMS R , PUT. 

Algorithm for insertion opera.tion is given below: 

Step 1 : Initialize HRECP = 0. Pind overflow cylinder nunber crorre spending 
to relation RfilCD and store it in OVERCY. 

Step 2; Initialize ASIOCP, SIOCR. Increment MEECP by 1. Clear flags 
POUIIDP, OVERP, PIEDXP. 

Step 3: Is ]mECP> ACTIRS? If yes go to Step 4; else go to Step 7. 

Step 4: Is PIKDXP flagset? If yes go to Step 5 1 else go to Step 6. 

Step 5: Write back primary index table on disk. 

Step 6: Return to calling program. 

Step 7: Print Record Ro. EEiECP. 

Step 8; Call subroutine TRSUSE to find cylinder and sector no. 

Step 9; Is MTCHPR = set? If yes go to Step 11 5 else go to Step 10, 

Step 10: Set PIITOX flag. Transfer primary key value of ci^rent record 
in user file to the last record in primary inde37&able- Go to 
Step 8. 

Step 11 : Is MTCHSR = set? If yes go to Step 135 else go to Step 12. 

Step 12: Transfer primary tey value of current record in user file to 

last record in current secondary index table. Goto Step 8. 

Step 13: CRRTCY-^ CYIiEDR. 

Step 14: Read sector no. SURSEC from cylinder no. GYIilPR. 

Step 15: C0MT6 = 0. 



56 


Step 1 6 : C0Um)6 = COUNK+I . 

Step 17s Is COUMT6 '^IL'iXRC? If yes go to Step 26; else go to Step 18. 

Step 18 5 Is primiry key velLue in current record of sector blank? If yes, 

go to Step 22; else go to Step 19. 

Step 19: Is primary key v..iue of current record in sector = primary key 

vtilue of current record in user file? If yes go to Step 20; else 

go to Step 21 . 

Step 20: Set Pl.rg POUFOP. 

Step 21 : Upd.-ite aSIOCP, SIOGR. Goto Step 16. 

Step 22: Transfer current record in user file to current record in sector. 
V/rite back sector on disk. 

Step 23 : Update secondary index table and write it back on disk. 

Step 24: Give message, "Record processed." 

Step 25: Take next record in user file. Go to Step 2. 

Step 26; Initialise ASLOCP, SIOGR. Is OYRRCY = 0? If yes, go to Step 29; 
elte go to Step 27. 

Step 27: Read la st 2 bytes of sector and store it in HEWSS. Is FEWSS = 
2 OO 4 O? If yes go to Step 29; else go to Step 28. 

Step 28 : CRNTCY-^ CYLHDR 
SORSEC HEWSS. 

Set flag OVLRP. Read sector no. SURSEC from cylinder CRFTCY. 

Go to Step 15- 

Step 29: Is flag POUHDP = set? If yes go to Step 42; else go to Step 30, 

Step 30: Set flag OYERP. Is OYERCY = 0? If yes go to Step 37; el® go to 
Step 31 . 

Step 31 : Read first sector from cylinder OYERCY- Read first 2 bytes of 
this sector into HEWSS. Is FEWSS = i-.st sector of a cylinder? 

If yes, go to Step 32; else go to Step 35- 

Step 32: Give message "Ho empty sector available in overflow cylinder". 

Go to Step 25- 

Step 33 ; Pind out next available sector in overflow cylinder and store it 
in HEWSS. 
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Step 34! Store MtiY/SS in first two bytes of first sector of overflow 
cylinder. 

Step 35 : Store HEWSS to last two bytes of sector SURSEG o^^ cylinder 
CEmCY. 

Step 36: SURSEG -«-I®WSS, 

Rill up sector are i with blanks. Go to Step 22. 

Step 37 : Rind out the first available empty cylinder in disk. Is it 
available ? If yes go to Step 3'^ else go to Step 38. 

Step 38: Give message, "Ro empty cylinder availble in disk". Go to Step 25- 

Step 39: Store cylinder no. cf newly available cylinder in OVERCY. Store 
OVERCY in relation dL rectory. Store 2 in last 2 bsrbes of sector 
SURSEG of cylinder no. CYIITDR. 

Step 40: SURSEG-*- 1 

Rill up sector area by blanks. Store 2 in first two bytes of 
first sector of cylinder OVERCY. 

Step 41 : Rill up sector area by blanks. SURSEG*^ 2. Go to Step 22. 

Step 42: Comp 're primary key value cf current record in user file with 
highest key entry in current record of secondary index table. 

Are they equal? If yes go to Step 43; else go to Step 30. 

Step 43: 00UNT3 = C0Uira3+1 . 

Is the current record of secondary index table last record? 

If yes, go to Step 46; else go to Step 44. 

Step 44; Ishighest key entry in current record of primary index' table 
prim.ory key value. of cuprantj-yecord in user file? If yes 
go to Step 45; else go to Step 30. 

Step 45: Read SURSEG from secondary index table. Go to Step 14. 

Step 46: ODUMTI = OEWTI-H. 

Read secondary index table from first sector of cylinder no. 

H CYIHDR. Is highest key value in record no, G0UHE1 blank? If 

yes, go to Step 47l else go to Step 48. 

Step 47: Read SURSEG from secondary index table. G0U1«3 =0, Go to 
Step 44, 

Step 48: COUNT 0 = COUNTO + 1 , 

Is OOUNTO = NIN? If yes go to Step 30; ed^e go to Step 49 . 



Is highest pria uy key entry in oiirrenfc record cf priiii.ory 
index tab3e ^ primf-iry key value of current reford in user 
file? If yes, go to Step 50? else go to Step 30. 

Read CYINDE, KRECSE froa priLi.jry index table. Call sub- 
routine SUSE to find SURSEC. Is flcg M.ICHSR = Set? If 
yes, go to Step 13; else go to Step 30. 


End of iilgorithm 



Flowchart for Insertion 


< SUBEDUTIIE INSERT \ 
\ / 


^ 

I KRECP = 0; Find OVERCY j 

J 



j Initialise ASIDCP, SIDCRj 
j clear FOUHDF, OVERF 
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0Yi;EGY =0?'^ 


Yes 


m 


Read last 2 bytes from 
SCTEAR in HEWSS 


CEOTCY=0Vj 5RCY r 
SUESEC=HEWSS j 


.Ro 


/ \ 

mms = 20040 ; 


Set OTEEP 


I 


Jes 


j 

Read sector 

iSURSEC from 

j CEETOY 


'\ I 


No 


/ 

EOUKDE = 

\ 

S 

set? j)- 


1 


I B 


./ OYERCY = 0? ■ y 

■ / 


Yes 



E 


Read 1st sector of 
OVERCY. Read 1 st 
word and store it 
in NEWSS 


¥ 


'■t- . 


NEYraS = last sector 
of cylinder? / 

No 


Call NSTSEC and store in 
NEWSS 


■ Yes 


"No space available 
in overflow cylinder" 


I 


Store NEWSS in 1st word and write it back 
in first sector of OYERCY* Read sector 
SUESEC from cylinder CENTCY and store 
NEWSS in last 2 bytes and write it back. 
SDRSEC = NEWSS 
Mate SCIRAR blank. 
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^es 




Stort! OVERCY in Relation Directory. 
Stare 2 in last 2 bytes of SCTRAR 
and write it back in sector SDESEG 
of CYDM)R. SURSEC = 1 
Blank SCTRAR and put 2 in first 2 
bytes. Write back SCTRAR in seccbor 
SURSEC of 07ERCY. Blank SCTRAR. 
SURSEC = 2 


1 ? 



”10 cylinder 
available” 


? 
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f 

jL 


Update secondary index table and 
write it back. ^’Record processed^^* 
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! Compare primary key value 
secondary index table entry. 

\ Are they equal? , 


$Yes 


Is it last entry of secondary \, 
index table ? / 


yes 


Ho 





Ho 


' call OOMPRI Ho 
,Mi\TGH5'=Set? / 




C0UHT1 = C0UHT1 + 1 
Read secondary index table; check 
next entry fcr blank. 


Read SDRSEC from 
secondary index table 


r Kj 


( 

/ Is it blcank? ^ 


VYes 


Calculvate SURSBC. Read 
secondary index table. 
C0UNT3=0 









8. Risuiirs and DISGUSSIOIfS 


For updating operation, SCaJJ subroutine and all the prcgram 
subroutines described so far are to be loaded into memory. SCAl'I 
occupies memory location from 30000 to 46254 and rest of the jrogram, 
subroutines occupy memory location from 54000 to IIO5OO, After load- 
ing, execibion is to be started from address 54000- 'Then execution 
of Phase-I is over, control automatically transfers to Phase-II. 

Typical examples of different messages received in keyboard 
while updating program is being executed are given on • the 
next page. 

Discussion 

Algorithms written for modification and insertion operations 
have the following limitations : 

In single-relation modification, all the fields vihich are common 
between specified relation and user-file are being updated in the 
specified relation only. If these fields exist in any relation other 
than the sp 3 cified one, this will lead to discrepancy in data base. 

So before processing single-relation modification operation, it should 
be checked from PDIST that such a situation does not arise. Horever, 
if such a situation arises, processing should not stop but it should 
automatically transfer to group-relation modification operation. 

On bhe other hand, in group-relation modification, it may happen 
that a field specified in user file exists in more than one relation 
having di-^ r^nt primary keys. According to the algorithm for group- 
relation modification this field ^«L11 be modified only in those relatio.^ 
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OPERATION ST ffiTS, SPRCIPY TYPh’ OP JOB 

PGR UPDATING PxROSS U 

POE RETRIJVAL PROSS E 

POE DBA PRESS D 

PUAN GIVE LINO PEODU 


ABC 


GIVE IDEIWn'ICATDxJ CXUlil 


GIVI im’UT jiJDim 
POE CARD READER PRiSS C 
POE KEYBC/iRD PRJS3 K 
THRU GIVI LIIO PEEDC 


3PECIPY US 'R PILE WITH PRIMARY KEY AS PIEST EITRY 


POILOv/IlIG T.YBLC PRINTS USJR PILE 
FIRST COLIJlRI GIVES FIELD COID. 

SECOND COLUMN GIVES PI ELD L13NGIH 

THIRD COLUIW GIVES DISTANCE IN DaTA CaRD 

FOURTH COLmiM GIVES DISTANCE AFTER REMOVING FILLERS. 

FIFTH COLUMN GIVES FORM iff CODE. 

FI 8. 0. 0. 

F 45 8. 60. 8. 

p 25 6. 108. 16. 

IS IT O.K.? 

SPECIFY INPUT IVDSDIUM FOR DATA 
C 

CARD-READER READY? 


05001 0 
030010 
03 0006 


RECORD NO . 1 . , ACCEPTED AND 

RECORD HO. 2 ., ACCEPTED AND 

RECORD NO. 3 ., ACCEPTED AND 

RECORD ID . 4 . , ACCEPTED AND 

RECORD NO . 5 ACCEPTED AND 

RECORD NO. 6,, ACCEPTED AND 

END OF DATA 

JD . OF EJICOCDS IN USER FIIE 
**P[iASE-I OVER** 

SPECIFY TYPE OF UPDATING 

CODE IDR Dal'ilT=D,INSERT=1 , MODIFY 


STORED 

STORED 

STORED 

STORED 

STORED 

STORED 

6 . 


■=M 


SPECIFY Y/HjHHER UPDATING IS ON SINGLE 
SINGLS=S, GROUP=G 
S 

SPECIFY REIilTION CODE 


RELATION CE GROUP OP 


RELATIONS 


ALL SPECIFIED FIELDS ARE NOT PRESENT IN GIVEN RELATION 
SHALL I PROCEED? 


RECORD NO . 
RECORD NO, 
RECORD ID. 
RECORD NO. 

record no. 

RECORD NO- 


1 ., PROCESSED 

2 ., PROCESSED 

3 ., PROCESSED 
4 ., PROCESSED 

5 ., PROCESSED 

6 .. PROCESSED 



iix:ample-2 
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OPBRATDN STARTS, SPSCIRY TYPE OR JOB 

FOR UPmTING PRESS U 

FOR RETRIEVAL HIESS E 

FOR DBA PIESS D 

THEN GIVE LINE FEEDU 


ABC 


GITE IDENTIFICATION COEE 


GIVE INPUT MSDIOM 
FOR CARD READER PRESS C 
FOR KEYBOARD PRESS K 
THEN GIVE LINE FEEDS 


SPECIFY USiR FILE TfITH PRIMARY KEY AS FIRST ENTRY 
22 PNUI4 FI X*8 . 

00 


FOLLOWING TABLE PRINTS USER FILE 
FIRST COLUMN GIVES FIELD CO IE. 

SECOND COLUT.IN GIVES FIELD LENGTH 

THIRD COLUMN GIVES DISTANCE IN DATA CARD 

FOURTH G0LU1.IN GIVES DISTANCE AFTER EEMDVING FILIERS. 

FIFTH COLUMN GIVES FORMAT CODE 


IS IT O.K.? 


SPECIFY INPUT MEDIUM FOR DATA 
K 

GIVE INPUT DATA FROM KEY-BOARD 
IC 00030 

RECORD NO . 1 . , ACCEPTED AND STORED 

IC 00040 

RECORD HO. 2 ACCEPTED AND STORED 


END OF DATA 

NO . OF RECORDS IN USER FILE 2 

**EHASB-I OVER** 

SPECIFY TYPE OF UPDATING 

CODE FOR DELET=D,INSEET-I,M0DIFY=M 


SPECIFY 'SHETHER UPDATING IS 


ON SINGLE RELATION OR 


GROUP OF RELATIONS 


SINGLE=S, GEOUP=G 

Gr 


***-'f*ESB, TIDN no. 
RECORD NO. 1 

RECORD NO. . 2 
*****RELATI0N ICl. 
RECORD ro. 1 

RECORD 1® . 2 . , 


30RD DOES HOT EXIST IN SECTOR 


3 ORD DOES NOT EXIST IN SECTOR 
)ORD DOES NOT EXIST IN SECTOR 
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whose primary key is the same as primary key of user file. This may 
again lead to discrepancy in data tase. Hence after a group— relation 
modification is over, it should be checked from FDLIST whether such a 
situation arises and if it does, processing should not stop but it 
should repeat itself and ask for a user file with different primary 
key. 

While inserting a record it is never being checked vfcether the 
•field-vr’lues inserted in a relation for a given primary key are con- 
sistent with field values for the same primary key in the same rela- 
tion or other relation. As a result, it may semetime happen that 
for Hie same primary key there may be records with different field- 
values for a single-valued field, creating discrepancy in data base. 
This can be avoided if all these field values for given primary keys 
are Retrieved from data base before starting insertion operation and 
manually verifying that there is no inconsistency between retrieved 
information and informations going to be inserted. This verification 
can also be done by writing a program. 

Removing all these limitations of Modify and Insert algorithms 
and ma ki ng these algorithms more flexible and more realistic may be 
a furthei’ extension of 1his work. 
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